1. The Field of the Invention
The present invention relates to computer network security, and more specifically, to mechanisms for establishing a secure context at an electronic communications end-point.
2. Background and Relevant Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter both referred to as a “computing system”) to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., packetizing, routing, flow control). The Open System Interconnect (“OSI”) model is an example of a networking framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring an electronic message into seven distinct “layers,” each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to higher intermediate layers and then eventually received at the application layer. The application layer, the upper most layer, is responsible for supporting applications and end-user processes. Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer protocol is the Transmission Control Protocol (“TCP”).
Often, when two computing systems desire to communicate with each other, for example, by transferring a number of electronic messages, the two computing systems will establish a secure context. That is, the two computing systems can authenticate and agree on the mechanisms used to secure the data (e.g., data within electronic messages) transferred between the computing systems. This can often include activating security mechanisms within protocol stacks operating at each of the two computing systems.
To initiate the establishment of a secure context, two computing systems typically exchange a number of configuration parameters (often referred to as performing a “handshake”). One example of a handshake is the Secure Socket Layers (“SSL”) handshake sequence frequently used to establish a secure context between a client computing system (hereinafter referred to as a “client”) and a server computing system (hereinafter referred to as a “server”) on the Internet. SSL is typically configured to operate between a transport layer (e.g., a layer implementing TCP) and higher layers in a protocol stack (e.g., an application layer). During an SSL handshake sequence, a client and server can exchange SSL version numbers, cipher settings, and other communication information necessary to communicate using SSL. Once established, an SSL secure context allows the client and server to cooperate in the creation of session keys for encryption, decryption, and tamper detection (signing) of electronic messages transferred between the client and server.
Unfortunately, the information that is exchanged between the client and the server during many, if not all, conventional handshake sequences is prescribed by the handshake protocols used to implement the handshake sequences. For example, an SSL handshake sequence is often limited to exchanging information about supported versions of SSL. Handshake protocols can, in some instances, make decisions based on the prescribed information that is exchanged between a client and server. Thus to a limited extent, prescribed rules can vary a subsequent portion of prescribed information based on a determination with respect to an initial portion of prescribed information. For example, a handshake protocol may detect that a certain version of SSL is mutually supported (an initial portion) and as a result vary the prescribed information that is exchanged (a subsequent portion) during the SSL handshake. However, these limited decisions are for the most part made based on prescriptive rules that are inherent to a handshake protocol. Thus, although a handshake protocol may vary exchanged information somewhat, the exchanged information is still limited to that resulting from the prescriptive rules inherent in the handshake protocol.
Altering the prescriptive rules and/or prescribed information for a handshake protocol can lead to incompatibilities since handshake protocols, such as, for example, the SSL handshake protocol, are often well established and may even be standards. Thus, altering handshake protocol functionality at one computing system may cause incompatibilities with large numbers of other computing systems. Further, even if a handshake protocol were compatibly altered, there is little chance that every possible combination of properties for a security context could be implemented.
Most application layer processes (in part due to the configuration of protocol stacks) lack the ability to alter functionality at lower layers of a protocol stack where handshake protocols typically function. Thus, if an application layer process desired a combination of security context properties that were not supported by a handshake protocol, the application layer process would have limited, if any, mechanisms to create a security context with the desired security context properties. For example, it may be that an application designer desires for a particular distributed application to utilize SSL version 2 even if both a client and server support SSL version 3. However, the application designer may be precluded from implementing this desired functionality due to a prescriptive rule of the SSL handshake protocol (e.g., a rule that forces utilization of SSL version 3 when computing systems support SSL version 3). This is unfortunate as the application designer is often in a better position to decide the desired security context properties for an application.
Further, many conventional handshake protocols used to establish a secure context are point-to-point protocols that permit establishment of a security context between two connected points. However, these same handshake protocols do not permit security contexts to be established between computing systems that are separated by intermediaries, such as, for example, by a number of intermediary computing systems in a routing path. Thus, to securely process electronic messages transferred between a client and a server, separate security contexts (which can each have different properties) may be established between a client, any intermediaries, and a server.
FIG. 6 is a prior art Figure illustrating client 601, intermediary 605, and server 602. In FIG. 6, security context 612 can be established between client 601 and intermediary 605 based on information that is exchanged between client 601 and intermediary 605. Likewise, security context 613 can be established between intermediary 605 and server 602 based on information that is exchanged between intermediary 605 and server 602. However, as the information exchanged between client 601 and intermediary 605 can differ from the information exchanged between intermediary 605 and server 602, the properties of security context 612 and security context 613 can also differ. For example, security context 612 may support Windows NT LAN Manager (“NTLM”) authentication but not Kerberos authentication (which is often considered more secure than NTLM authentication), while security context 613 supports both Kerberos authentication and NTLM authentication.
This can be problematic when an electronic message is sent from client 601 to server 602. Server 602 may have to rely on security evaluations made by intermediary 605 and trust intermediary 605's handling of the content of the electronic message. However, the properties of the security contexts 612 and 613 might differ from a security context that could be established directly between client 601 and server 602. Thus, subjecting the content of an electronic message to the security mechanisms of intermediary 605 may be less secure than if the content of the electronic message were transferred directly between client 601 and server 602.
Therefore systems, methods, computer program products, and data structures for establishing a secure context at a communications end-point would be advantageous.